JavaScript 모듈 리스코프 치환 원칙: 행위 호환성

리스코프 치환 원칙(LSP)은 객체 지향 프로그래밍의 5가지 SOLID 원칙 중 하나입니다. 이 원칙은 프로그램의 정확성을 변경하지 않고도 서브타입을 기본 타입으로 대체할 수 있어야 한다고 명시합니다. JavaScript 모듈의 맥락에서 이는 모듈이 특정 인터페이스 또는 기본 모듈에 의존하는 경우, 해당 인터페이스를 구현하거나 해당 기본 모듈에서 상속받는 모든 모듈은 예기치 않은 동작을 일으키지 않고 해당 위치에서 사용될 수 있어야 함을 의미합니다. LSP를 준수하면 더욱 유지보수가 용이하고 견고하며 테스트 가능한 코드베이스를 얻을 수 있습니다.

리스코프 치환 원칙(LSP) 이해

LSP는 Barbara Liskov의 이름을 따서 명명되었으며, 그녀는 1987년 기조 연설 "Data Abstraction and Hierarchy"에서 이 개념을 소개했습니다. 원래 객체 지향 클래스 계층 구조의 맥락에서 공식화되었지만, 이 원칙은 특히 모듈 구성 및 종속성 주입을 고려할 때 JavaScript의 모듈 설계와도 관련이 있습니다.

LSP의 핵심 아이디어는 행위 호환성입니다. 서브타입(또는 대체 모듈)은 기본 타입(또는 원래 모듈)과 동일한 메서드 또는 속성을 단순히 구현해서는 안 됩니다. 또한 기본 타입의 기대와 일관된 방식으로 동작해야 합니다. 즉, 클라이언트 코드에서 인식되는 대체 모듈의 동작은 기본 타입에 의해 설정된 계약을 위반해서는 안 됩니다.

공식 정의

공식적으로 LSP는 다음과 같이 명시할 수 있습니다.

φ(x)를 타입 T의 객체 x에 대해 증명 가능한 속성이라고 합시다. 그러면 S가 T의 서브타입인 경우 φ(y)는 타입 S의 객체 y에 대해 참이어야 합니다.

더 간단히 말해서, 기본 타입이 동작하는 방식에 대해 단언할 수 있다면 해당 단언은 해당 서브타입에 대해서도 여전히 유효해야 합니다.

JavaScript 모듈의 LSP

JavaScript의 모듈 시스템, 특히 ES 모듈(ESM)은 LSP 원칙을 적용하기 위한 훌륭한 기반을 제공합니다. 모듈은 인터페이스 또는 추상적 동작을 내보내고 다른 모듈은 이러한 인터페이스를 가져와 활용할 수 있습니다. 한 모듈을 다른 모듈로 대체할 때 행위 호환성을 확인하는 것이 중요합니다.

예제: 알림 모듈

간단한 예제인 알림 모듈을 고려해 보겠습니다. 기본 `Notifier` 모듈부터 시작하겠습니다.

            
// notifier.js
export class Notifier {
  constructor(config) {
    this.config = config;
  }

  sendNotification(message, recipient) {
    throw new Error("sendNotification must be implemented in a subclass");
  }
}

            

              
                Copy
              
            
          

이제 두 개의 서브타입인 `EmailNotifier`와 `SMSNotifier`를 만들어 보겠습니다.

            
// email-notifier.js
import { Notifier } from './notifier.js';

export class EmailNotifier extends Notifier {
  constructor(config) {
    super(config);
    if (!config.smtpServer || !config.emailFrom) {
      throw new Error("EmailNotifier requires smtpServer and emailFrom in config");
    }
  }

  sendNotification(message, recipient) {
    // Send email logic here
    console.log(`Sending email to ${recipient}: ${message}`);
    return `Email sent to ${recipient}`; // Simulate success
  }
}


// sms-notifier.js
import { Notifier } from './notifier.js';

export class SMSNotifier extends Notifier {
  constructor(config) {
    super(config);
    if (!config.twilioAccountSid || !config.twilioAuthToken || !config.twilioPhoneNumber) {
      throw new Error("SMSNotifier requires twilioAccountSid, twilioAuthToken, and twilioPhoneNumber in config");
    }
  }

  sendNotification(message, recipient) {
    // Send SMS logic here
    console.log(`Sending SMS to ${recipient}: ${message}`);
    return `SMS sent to ${recipient}`; // Simulate success
  }
}

            

              
                Copy
              
            
          

마지막으로 `Notifier`를 사용하는 모듈입니다.

            
// notification-service.js
import { Notifier } from './notifier.js';

export class NotificationService {
  constructor(notifier) {
    if (!(notifier instanceof Notifier)) {
      throw new Error("Notifier must be an instance of Notifier");
    }
    this.notifier = notifier;
  }

  send(message, recipient) {
    return this.notifier.sendNotification(message, recipient);
  }
}

            

              
                Copy
              
            
          

이 예에서 `EmailNotifier`와 `SMSNotifier`는 `Notifier`로 대체 가능합니다. `NotificationService`는 `Notifier` 인스턴스를 기대하고 해당 `sendNotification` 메서드를 호출합니다. `EmailNotifier`와 `SMSNotifier`는 모두 이 메서드를 구현하고 구현은 다르지만 알림을 보내는 계약을 이행합니다. 성공을 나타내는 문자열을 반환합니다. 결정적으로 알림을 보내지 않거나 예기치 않은 오류를 발생시키는 `sendNotification` 메서드를 추가하면 LSP를 위반하게 됩니다.

LSP 위반

결함이 있는 `SilentNotifier`를 도입하는 시나리오를 고려해 보겠습니다.

            
// silent-notifier.js
import { Notifier } from './notifier.js';

export class SilentNotifier extends Notifier {
  sendNotification(message, recipient) {
    // Does nothing!  Intentionally silent.
    console.log("Notification suppressed.");
    return null; // Or maybe even throws an error!
  }
}

            

              
                Copy
              
            
          

`NotificationService`에서 `Notifier`를 `SilentNotifier`로 바꾸면 애플리케이션의 동작이 예기치 않은 방식으로 변경됩니다. 사용자는 알림이 전송될 것으로 예상할 수 있지만 아무 일도 일어나지 않습니다. 또한 `null` 반환 값은 호출 코드가 문자열을 예상하는 문제를 일으킬 수 있습니다. 이는 서브타입이 기본 타입과 일관되게 동작하지 않기 때문에 LSP를 위반합니다. `NotificationService`는 이제 `SilentNotifier`를 사용할 때 손상됩니다.

LSP 준수의 이점

• 코드 재사용성 증가: LSP는 재사용 가능한 모듈 생성을 촉진합니다. 서브타입은 기본 타입으로 대체 가능하므로 기존 코드를 수정하지 않고도 다양한 컨텍스트에서 사용할 수 있습니다.
• 유지보수성 향상: 서브타입이 LSP를 준수하면 서브타입의 변경 사항으로 인해 애플리케이션의 다른 부분에서 버그나 예기치 않은 동작이 발생할 가능성이 줄어듭니다. 이를 통해 코드를 유지보수하고 시간이 지남에 따라 발전시키기 쉬워집니다.
• 테스트 용이성 향상: 서브타입을 기본 타입과 독립적으로 테스트할 수 있기 때문에 LSP는 테스트를 단순화합니다. 기본 타입의 동작을 확인하는 테스트를 작성한 다음 해당 테스트를 서브타입에 재사용할 수 있습니다.
• 결합도 감소: LSP는 모듈이 구체적인 구현이 아닌 추상적 인터페이스를 통해 상호 작용할 수 있도록 하여 모듈 간의 결합도를 줄입니다. 이를 통해 코드를 더 유연하게 만들고 변경하기 쉽게 만듭니다.

JavaScript 모듈에서 LSP를 적용하기 위한 실용적인 지침

1. 계약에 의한 설계: 모듈의 예상 동작을 지정하는 명확한 계약(인터페이스 또는 추상 클래스)을 정의합니다. 서브타입은 이러한 계약을 엄격하게 준수해야 합니다. TypeScript와 같은 도구를 사용하여 컴파일 시간에 이러한 계약을 적용합니다.
2. 사전 조건 강화 방지: 서브타입은 기본 타입보다 더 엄격한 사전 조건을 요구해서는 안 됩니다. 기본 타입이 특정 범위의 입력을 허용하는 경우 서브타입은 동일한 범위 또는 더 넓은 범위를 허용해야 합니다.
3. 사후 조건 약화 방지: 서브타입은 기본 타입보다 더 약한 사후 조건을 보장해서는 안 됩니다. 기본 타입이 특정 결과를 보장하는 경우 서브타입은 동일한 결과 또는 더 강력한 결과를 보장해야 합니다.
4. 예기치 않은 예외 발생 방지: 서브타입은 기본 타입이 발생시키지 않는 예외를 발생시켜서는 안 됩니다(해당 예외가 기본 타입에서 발생한 예외의 서브타입인 경우는 제외).
5. 상속 현명하게 사용: JavaScript에서는 프로토타입 상속 또는 클래스 기반 상속을 통해 상속을 달성할 수 있습니다. 과도한 결합 및 깨지기 쉬운 기본 클래스 문제와 같은 상속의 잠재적인 함정에 유의하십시오. 적절한 경우 상속보다 구성을 사용하는 것을 고려하십시오.
6. 인터페이스 사용 고려(TypeScript): TypeScript 인터페이스를 사용하여 객체의 모양을 정의하고 서브타입이 필요한 메서드와 속성을 구현하도록 강제할 수 있습니다. 이는 서브타입을 기본 타입으로 대체할 수 있도록 하는 데 도움이 될 수 있습니다.

고급 고려 사항

가변성

가변성은 함수의 매개변수 및 반환 값의 타입이 치환 가능성에 미치는 영향을 나타냅니다. 세 가지 유형의 가변성이 있습니다.

• 공변성: 서브타입이 기본 타입보다 더 구체적인 타입을 반환하도록 허용합니다.
• 반공변성: 서브타입이 기본 타입보다 더 일반적인 타입을 매개변수로 허용하도록 허용합니다.
• 불변성: 서브타입이 기본 타입과 동일한 매개변수 및 반환 타입을 갖도록 요구합니다.

JavaScript의 동적 타이핑은 가변성 규칙을 엄격하게 적용하는 데 어려움을 겪습니다. 그러나 TypeScript는 가변성을 보다 제어된 방식으로 관리하는 데 도움이 되는 기능을 제공합니다. 핵심은 타입이 전문화된 경우에도 함수 서명이 호환성을 유지하도록 하는 것입니다.

모듈 구성 및 종속성 주입

LSP는 모듈 구성 및 종속성 주입과 밀접한 관련이 있습니다. 모듈을 구성할 때 모듈이 느슨하게 결합되어 있고 추상적 인터페이스를 통해 상호 작용하는지 확인하는 것이 중요합니다. 종속성 주입을 사용하면 런타임에 인터페이스의 다른 구현을 주입할 수 있으며 이는 테스트 및 구성에 유용할 수 있습니다. LSP 원칙은 이러한 대체가 안전하고 예기치 않은 동작을 일으키지 않도록 하는 데 도움이 됩니다.

실제 예제: 데이터 액세스 레이어

다른 데이터 소스에 대한 액세스를 제공하는 데이터 액세스 레이어(DAL)를 고려해 보겠습니다. `MySQLDataAccess`, `PostgreSQLDataAccess` 및 `MongoDBDataAccess`와 같은 서브타입이 있는 기본 `DataAccess` 모듈이 있을 수 있습니다. 각 서브타입은 동일한 메서드(예: `getData`, `insertData`, `updateData`, `deleteData`)를 구현하지만 다른 데이터베이스에 연결합니다. LSP를 준수하면 해당 모듈을 사용하는 코드를 변경하지 않고도 이러한 데이터 액세스 모듈 간에 전환할 수 있습니다. 클라이언트 코드는 `DataAccess` 모듈에서 제공하는 추상적 인터페이스에만 의존합니다.

그러나 MongoDB의 특성상 `MongoDBDataAccess` 모듈이 트랜잭션을 지원하지 않고 다른 데이터 액세스 모듈이 트랜잭션을 지원하는 동안 `beginTransaction`이 호출될 때 오류를 발생시킨다고 상상해 보십시오. 이는 `MongoDBDataAccess`를 완전히 대체할 수 없기 때문에 LSP를 위반합니다. 잠재적인 해결책은 `MongoDBDataAccess`에 대해 아무것도 수행하지 않는 `NoOpTransaction`을 제공하여 작업 자체가 아무 작업이 아니더라도 인터페이스를 유지하는 것입니다.

결론

리스코프 치환 원칙은 JavaScript 모듈 설계와 매우 관련이 있는 객체 지향 프로그래밍의 기본 원칙입니다. LSP를 준수하면 더욱 재사용 가능하고 유지보수 가능하며 테스트 가능한 모듈을 만들 수 있습니다. 이는 시간이 지남에 따라 진화하기 쉬운 보다 강력하고 유연한 코드베이스로 이어집니다.

핵심은 행위 호환성이라는 것을 기억하십시오. 서브타입은 기본 타입의 기대와 일관된 방식으로 동작해야 합니다. 모듈을 신중하게 설계하고 대체 가능성을 고려함으로써 LSP의 이점을 얻고 JavaScript 애플리케이션을 위한 보다 견고한 기반을 만들 수 있습니다.

리스코프 치환 원칙을 이해하고 적용함으로써 전 세계의 개발자는 최신 소프트웨어 개발의 과제를 충족하는 보다 안정적이고 적응 가능한 JavaScript 애플리케이션을 구축할 수 있습니다. 단일 페이지 애플리케이션에서 복잡한 서버 측 시스템에 이르기까지 LSP는 유지보수가 용이하고 강력한 코드를 만드는 데 유용한 도구입니다.